The AudioTrackPositionTracker needs to correct positions by
the speed set on the AudioTrack itself whenever it makes
estimations based on real-time (=the real-time playout
duration is not equal to the media duration played).

This happens for the main playback path already, but not for
the mode in which the position is estimated from the playback
head position and also not in the phase after the track has
been stopped. Both cases are not very noticeable during
normal playback, but become relevant when playing in offload
mode.

PiperOrigin-RevId: 507736408
(cherry picked from commit 01d7bc7)

PiperOrigin-RevId: 507784608
(cherry picked from commit ecd91d8)

…in-cached-content-index

PiperOrigin-RevId: 508323432
(cherry picked from commit 1249dcd)

PiperOrigin-RevId: 508602059
(cherry picked from commit 6066ce4)

`TrackSelectorResult.rendererConfigurations` can contain null elements:
> A null entry indicates the corresponding renderer should be disabled.

This wasn't caught by the nullness checker because `ExoPlayerImpl` is
currently excluded from analysis.

#minor-release

Issue: google/ExoPlayer#10977
PiperOrigin-RevId: 508619169
(cherry picked from commit a6dfcf7)

The AsynchronousMediaCodecAdapter's queuing thread stores any exceptions
raised by MediaCodec and re-throws them on the next call to
queueInputBuffer()/queueSecureInputBuffer(). However, if MediaCodec
raises and error while queueing, it goes into a failed state and does
not announce available input buffers. If there is no input available
input buffer, the MediaCodecRenderer will never call
queueInputBuffer()/queueSecureInputBuffer(), hence playback is stalled.

This change surfaces the queueing error through the adapter's dequeueing
methods.

PiperOrigin-RevId: 508637346
(cherry picked from commit 7064310)

#minor-release

PiperOrigin-RevId: 509189206
(cherry picked from commit 5192962)

In parsing Describe RTSP response messages, IllegalArgumentExceptions are thrown for invalid parameters and values. These exceptions were not caught and crashed the Playback thread. Now these exceptions will be caught and their errors forwarded to the proper error handling listeners.

Issue: google/ExoPlayer#10971
PiperOrigin-RevId: 509207881
(cherry picked from commit a8c8745)

PiperOrigin-RevId: 509473556
(cherry picked from commit 56803bf)

The current javadoc refers to the SessionCallback#onConnected, which doesn't exist.

PiperOrigin-RevId: 510261965
(cherry picked from commit fc642eb)

#minor-release
Issue: #245
PiperOrigin-RevId: 510456793
(cherry picked from commit ba49b6b)

This call may cause performance overhead in some situations,
for example if the AudioTrack needs to query an offload DSP
for the current position. We don't need to check this multiple
times per doSomeWork iteration as the value is unlikely to
change in any meaningful way.

PiperOrigin-RevId: 510957116
(cherry picked from commit 9eccf09)

When rendering frames at a rate higher than the screen refresh rate,
e.g. playing at 8x, the player is releasing multiple frames at the same
release time (nanos) which are then dropped by the platform. The output
buffers are available later and as a result MediaCodec cannot keep up
decoding fast enough.

This change skips releasing multiple video frames on the same vsync
period and proactivelly drops the frame. The frame is counted as skipped
rather than dropped to differentiate with frames dropped due to slow
decoding.

PiperOrigin-RevId: 510964976
(cherry picked from commit ab7e84f)

The current logic uses manual array operations to keep track of pending
changes. Modernize this code by using an ArrayDeque and a data class.
This also allows to extend the output stream information in the future.

This also fixes a bug where a position reset accidentally assigns a pending
stream offset instead of keeping the current one.

PiperOrigin-RevId: 511787571
(cherry picked from commit f042012)

Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: google/ExoPlayer#10970

PiperOrigin-RevId: 512020154
(cherry picked from commit 93e1179)

This test became flaky after ab7e84f because some of the
unrealistic frame times ended up on the same release time.

Using realistic numbers avoids the flakiness.

PiperOrigin-RevId: 512566469
(cherry picked from commit 0c8ce18)

The output info for a new stream is marked pending until the last
sample of the previous stream has been processed. However, this fails
if the previous stream has already been fully processed. We need to
detect this case explicitly to avoid signalling the output change one
sample too late.

#minor-release

PiperOrigin-RevId: 512572854
(cherry picked from commit 7ffcc6f)

Some devices were reported to have wrong PerformancePoint sets
that cause 60 fps to be marked as unsupported even though they
are supported.

Issue: google/ExoPlayer#10898

PiperOrigin-RevId: 512580395
(cherry picked from commit d0cbf0f)

MediaCodecRenderer currently has two independent paths to trigger
events at stream changes:
 1. Detection of the last output buffer of the old stream to trigger
    onProcessedStreamChange and setting the new output stream offset.
 2. Detection of the first input buffer of the new stream to trigger
    onOutputFormatChanged.
Both events are identical for most media. However, there are two
problematic cases:
  A. (1) happens after (2). This may happen if the declared media
     duration is shorter than the actual last sample timestamp.
  B. (2) is too late and there are output samples between (1) and (2).
     This can happen if the new media outputs samples with a timestamp
     less than the first input timestamp.

This can be made more robust by:
 - Keeping a separate formatQueue for each stream to avoid case A.
 - Force outputting the first format after a stream change to
   avoid case B.

Issue: google/ExoPlayer#8594

PiperOrigin-RevId: 512586838
(cherry picked from commit 3970343)

Issue: #192
PiperOrigin-RevId: 508649684
(cherry picked from commit e1d12fc)

Playback parameter signalling can be quite complex because
 (a) the renderer clock often has a delay before it realizes
     that it doesn't support a previously set speed and
 (b) the speed set on media clock sometimes intentionally
     differs from the one surfaced to the user, e.g. during
     live speed adjustment or when overriding ad playback
     speed to 1.0f.

This change fixes two problems related to this signalling:
 1. When resetting the media clock speed at a period transition,
    we don't currently tell the renderers that this happened.
 2. When a delayed speed change update from the media clock is
    pending and the renderer for this media clock is disabled
    before the change can be handled, the pending update becomes
    stale but it still applied later and overrides any other valid
    speed set in the meantime.

Both edge cases are also covered by extended or new player tests.

Issue: google/ExoPlayer#10882

PiperOrigin-RevId: 512658918
(cherry picked from commit e79b47c)

Once the value returned from AudioTimestampPoller advances, we
only need getPlaybackHeadPosition to sample sync params and
verify the returned timestamp. Both of these happen less often
and we can avoid calling getPlaybackHeadPosition if we don't
actually need it.

PiperOrigin-RevId: 512882170
(cherry picked from commit 408b444)

#minor-release

PiperOrigin-RevId: 512890813
(cherry picked from commit a7faa5b)

#minor-release

PiperOrigin-RevId: 512897269
(cherry picked from commit 42fae15)

These are not supported by Dackka

#minor-release

PiperOrigin-RevId: 513176533
(cherry picked from commit c07cf3d)

…ire_file

PiperOrigin-RevId: 513213229
(cherry picked from commit 17499ce)

PiperOrigin-RevId: 513483809
(cherry picked from commit df11545)

#minor-release

PiperOrigin-RevId: 513488487
(cherry picked from commit cd753bd)

#minor-release

PiperOrigin-RevId: 513501046
(cherry picked from commit 6042bec)

#minor-release

PiperOrigin-RevId: 513533248
(cherry picked from commit 8498e4b)

PiperOrigin-RevId: 513556883
(cherry picked from commit e2cb32f)